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IN THE UNITED STATES PATENT AND TRADEMARK OFFICE 

In rc Application of: GATTO, Jean-Marie etal. Exr: Nirav B. PATE'L 

Serial Number; 10/789,975 Art Unit: 2135 

Filed February 27, 2004 Confirm No.: 9438 

For: Dynamic Configuration of a Gaming System Cust. No.: 86915 

Att y Dckt No.: CYBS5858 PRE-APPEAL BRIEF REQUEST 

FOR RECONSIDERATION 

Commissioner for Patents 
P. O. Box 1450 
Alexandria, VA 22313-1450 

Dear Sir: 

The present Pre- Appeal Brief Request for Review is submitted subsequent to the Request for Reconsideration 
of March 22, 2010 and in response to the Final Office Action November 24, 2009. This Request is filed with the 
fee for a two-month extension of time. Large Entity. 

*• Claim 25 bos vet to be substantively examined. 

Despite respectfully requesting for a substantive examination of claim 1 7 several times previously, the Office 

again dismissed (see Advisory Action of 04/06/2010) claim 25 as encompassing "limitations thai arc similar to 

claim 17. The claim limitation "packaging the code singed fsicj authorized software component into an 

installation package " is nothing more than just executable software with signature" 

Claim 25, however, recites: 

packaging the code signed authorized software components into an installation package; 

configuring install policies to install each code signed authorized executable software 
component contained in the installation package; 

configuring certificate rale policies to allow execution of the installed code signed 
authorized executable software component; 

configuring enforcement of the policies. 

Not once has the Office discussed the steps of "configuring install policies ..., configuring certificate 
rale policies ...: configuring enforcement of the policies ' or applied any art thereto. These positively recited 
Steps are not found in claim 1 7 or in any of the other independent claims. As such, they merit a considered 
substantive examination (what the applicant paid for) and not an out-of-hand dismissal thai: they are "similar to" 
the packaging steps of other claims when these steps, in fact, have no counterparts in any of the other pending 
claims. Moreover, the Office Review panel is also urged to consider the arguments beginning in the middle of 
page 1 3 of the Request for Reconsideration of March 22. 2010, relative to the "KSR" case. The lack of substantive 
examination of claim 25 alone, it is respectfully submitted, warrants withdrawal of the finality of the outstanding 
Office Actic. id the < r a new non-final O Action > a Notice of VHowance is appropriate 

II. The Office's Iatei^r i e i ^m]i ll Qjf ll ^m^;alvti er al. is Factually Incorrect 

Claim 1? recites "producing a separate and unique PRT certificate for each of the plurality of executable 
- ft' ; t i ■ ■ ■ v- •••eject to icee ng w 1 ;sc it ton within each gaming machine each soitwaic component 
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ub c ti tiding a unii etnii eo< going eat ectuabk i ue component 

subject to receiving certification with its respective separate and unique PK1 certf-ficate" 

Gunyakti et al. docs not tea< t separate jnjtLjyfiujn PKJ . for, each e\ec»|aMe 

software 1 1 com|ionen t, nor does Gunyakti use generated PKI certificates to code sign each of the different 
v< f t > < c lents v t in chi f f eneraies .olome license 

for a number of' products and it is this volume ! ense that i 1 with a j i t he license file 

224 - sec paragraph (0027). Therefore, it is the volume license itself that is signed with a private key and NOT 
"each of the plurality of executable software components", as required and claimed. In the Advisory Action, the 
Examine!' states "Therefore, each unique software assoe/aiecl with unique enterprise specific VLKfur a plurality of 
users". However, the claims do not recite that each software is associated with a unique volume license - for one 
or a plurality of users. The claims simply require "a separate and unique PKI certificate for each ... executable 
software component" and "code signing each executable software component ... with its respective separate and 
unique PKI certificate; '. As claimed, each executable software components is code signed with its associa^d 
"separate and nnigtie* PKf certificate, in direct contrast, in Gunyakti, it is the li cense to use the software that is 
signed, and not the software components themselves as in the claimed embodiments. This factual error represents 
yet another independent ground for allowing this application or re-opening the prosecution thereof, as appropriate. 

III. The Office** Interpretation of Yip et al. is Also Factually Incorrect 

The Office relies upon Yip for the same teaching of producing a separate and unique PKI certificate for 
each of the plurality of executable software components subject to receiving certification v. tthtn each gaming 
machine, and points to Figs. 2 and 3 and paragf p s ' „nd<H*40. 

In Yip, a conventional Certificate Authority (CA) issues a certificate 106 and an application-specific CA 
issues a corresponding appliea oi , lie certificate 206 bee paragraph (5042 The certificate 106 and 
application certificate 206 ate linked, such that when the certificate 106 is revoked, the application-specific 
certificates are also preferably revoked. See paragraph 0044. Thus, the application-specific certificate 206 is a 
"companion" to the certificate 106 

Note, however, that claim 1.7 recites: 

code signing each executable software component subject to receiving certification with 
its respective separate and unique PKI certificate, each respective PKI certificate being 
uniquely identified at least by a unique identifier that is uniquely associated with the 
executable software component such that identical executable software components in 
different ones of the plurality of gaming machines of the network connected gaming system 
are associated with identical Identifiers and sire code signed with identical PKf certificates, 
sttrih that non-identical executable soft ware components in dif ferent ones of the plurality of 
in _ ' tun t s t tt i\ k i n \ jj.ii ut i h i 0 n m s mil it ' s „m t 
with .separate and different. Ofsf ccrtiiiciucs and such Jhat no two non- identical executable 

softnaie,,, component', m ddfmnt ganun^ onnhincN aic code Muned with a same PKI 

ts ' .on o>. t omit i liuin •> i»t „ mphasis) 

As the application-specific certificate 20-1 is "for use with the parm uiai appln lion 201 . y i' 
foihws that t mutable software components in different ones of the plurality of gaming machines, in 
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Yip, would be ssociau i KI certificates s each application (each panuular apphcal o -t 

in Yip's language} would receive a diffident certificate 106 and corresponding different application-specific 

certificates 206. There is no teachin ot suggestion m Yip otherwise. 

Indeed, Yip . . y. from the ( aimed embodiments in which identical application-specific 
certificates a v. t k for identical executab t < ents in different h nu words the 

CA in Yip would not issue identical certificates 106 to more than o n icium. . in the < \ iwie 

identical eon pan u aj ca ion spec tin certificates 206 to more than on machine/user, as each certificate 106 is 
different and as the. applicatioi peer! erti ilea ws arc companh si tel iffcrent certificates 106 

Therefore, since each 'particular" application 201 receives a different certificate in Yip, there arc believed 
to be no grounds tor holding that Yip teaches or suggests {either alone or in combination with any or all of the 
other three applied references), the claimed limitation: 

identical executable software components in different ones of the plurality of gaming 
machines of the network connected gaming system arc associated with identical identifiers 
and are cork: signed with identical PK! certificates 

Therefore tin , • id inaj son of Gtmyakti and Yip does not yield the claim limitation (contrary to that stated 
in the advisory action of 4/n fit bee inning at fine 7), but instead would teach a PKI signed volume license 
(Gunyakfi) in combination with application-specific certificates in which each application received its own 
certificate, with identical executable software components on different gaming machines receiving different 
application-specific certificates 204, as again taught by Gwiyakti, which combination suggests nothing of the 
claimed embodiments and teaches away from any embodiment in which "identical executable software 
components in different ones of the plurality of gaming machines of the network connected gaming system are 
associated wit tical id n titters and arc c d i ncd ith identical PK.I certificates as claimed herein. 

IV. Fieres Does not Remedy The Fundamental Shortcomings of Goovakti-V jp 

The applied reference to Fieres teaches the issuance of application certifications to insure that applications 
operate at the propes raphi k granted foi that application b> m implication domain authority 22. 

However, there is no teaching or suggestion in Fieres that "identical executable software components in different 
ones of the plurality of gammg machines of the network connected gaming system are associated with identical 
identifiers and are code signed with identical PK.I certificates". Nor is there any teaching or suggestion in Fieres 
that "non-ide 1 ecu tab fiwart nponcnt ' f ercnt ones of the plu d t\ ot nning machines are 
associated with separate and different identifiers and are code signed with separate and different PKI certificates", 
as churned herein. 

Fieres does not teach or suggest that "no two non-identical executable software components in different 
gaming machines are code signed with a same PKI certificate", as claimed herein - nor has the Office identified 
where such tc eh i ,< iggestions ma\ be found, fa feet, there is no teaching or suggestion, in the context of the 
dish bunon ol crypto j bilities, that Fieres woul t!i( dt il executable components in different 
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machines to have identical certificates, as required herein. Such woul< el - measures. A 

dleg± thatj teaches apj i ccmficaU h applic >s (sec Ad vet i) docs si 

\-v ithou i ' hing the a fore i i < i 1 t .i \ e red 

com! . on . h tl ith i appik i !ik ,.ue 

V. Lambert Also l>pes not Provide foe Missing Teachings pr friggespons 

Lastly, Lambert was relied on for a teaching of method and system for securely control software 
exean'iot h\ , i t ?<7 classifying software and healing a rt * <m associated secwit} levei k executing 
executable software" (Advisory action of 4/6/2010). However, the pending claims do not a) identify software, b) 
classify software, c) locate a rule and/or d) locate an associated security level. More to the point, with respect to 
what is actually claimed. Lambert does not teach a software restriction policy certificate rule for each executable 
software component. Quite to the contrary. Lambert teaches one rule for an entire security level for executing 
executable software (see Abstract, lines 3-4). This means that executable software, in Lambert el al are associated 
with different security levels, and the rule for that security level may allow or disallow execution thereof Lambert 
also teaches a hierarchy of rules, to help distinguish which rule to use, should a piece of software have multiple 
classifications (see Abstract, last sentence). .In Column 15, lines 29-36, Lambert teaches how rules are selected 
and at lines 15-20 describes how rules determine the execution of the file, in Lambert, therefore, there is 
demonstrab l y no one-to-one relationship (a SRP for each executable software components) with executable 
software conn : Irak - .., . 

configuring a software restriction policy certificate rule for each of the plurality of 
executable software components and enforcing each of the software restriction policy 
certificate rules to allow execution of only those executable software components whose code 
Signed PKl certificate is determined to be authorized. 

To the contrary, Lambert ct al. teaches away from the claimed embodiments by teaching a onc-to-many 
relationship between the securit y rules and the executable solvate components , which is antithetical to the 
claimed embodiments, which require a software restriction policy for EACH of the plurality of executable software 
components. The applied combination, therefore, cannot be said to teach or to suggest the embodiment 
defined by claim 17. 

The arguments presented above relative to claim 17 are equally applicable to claim 20. Rather than repeat 
these here, reference is made to the arguments above, incorporated herein in their entirety. 

CI elected as 1 Lambert-Gu lud < th 

similar to that of claim claims 17 and 20. and the above arguments relative to Gunyakti and Yip apply. Although 
Lambert does teach rules based upon a path in Column 13. the applied combination of Lamhert-Gunyakti-Yip does 
not teach or suggest the claimed software restriction policy configuring and code signing steps, nor, by extension,, 
the claimed step of: 

enforcing the certificate software restriction policy configured for each of the code 
signed authorize!! executable software components of each of the constituent computers of 
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the gaming system, and 

fos the same argumcn iresei d relative to claim 17 which are also incoq i ik i herein in their entirety. 

Claim 24 recites the step of "producing a separate and unique PKI certificate for each of the plurality of 
executable software components within the gaming system subject to receive certification", and is believed to be 
he reasons developed above. Moreover, claim 24 also recites; 

code signing each software component subject to receive certification with its respective 
separate and unique PKf certificate; 

configuring a certificate software restriction policy for each of the respective separate 
and unique PKI certificates, ami 

enforcing the certificate software restriction policy for each of the respective separate 
and unique PKI certificates. 

In contradistinction, the primary reference to Gunyakti advocates volume licenses <-> how can a ypktmc 
license be interpreted as a "separate and unique PKI certificate for each of the plurality of executable software 
components"?}, Yip advocates companion application-specific certificates and Lambert calls for a hierarchy of 
rales to enable ti * > > » 1 > * ph mon The applied combination does not teach 

code signing each software component subject to receive certification wills its respective separate and unique PKI 
certificate (compare to Chmyakti's volume licenses), configuring a certificate software restriction policy for each of 
the respective separate and unique PKI certificates (compare with the one-to-many relationship of Lambert's rules 
to the applications) or enforcing the certificate software restriction policy for each of the respective separate and 
unique PKI certificates, as claimed herein. 

None of the applied references, alone or in combination, teach or suggest the claimed embodiments. The 
prior art (Yip) teaches that each "particular" software is signed with a different certificate. The prior art (Gunyakti) 
also teaches code .signing volume licenses it- executable software components). The prior art also teaches security 
levels (Lambert) or cryptographic levels and rules (Fieres) that may or may not allow execution of software 
components. It is respectfully submitted that the claimed elements are most assuredly not combined "according to 
known methods", as the Office asserts - nor would any combination of these references teach, suggest or result in 
the claimed embodiments. Therefore, reconsideration and withdrawal of the obviousness rejections are 
respectfully requested. 

Respectful ly s u bm i ttc d . 

Date: April 24, 2010 By; ^ 

Alan W. Young 
Attorney for Applicants 
Registration No. 37,970 

YOUNG LAW FIRM PC 
4370 Alpine R.d„ Ste. J 06 
Portoia Valley, CA 94028 
Tel.: (650)851-7210 

Fax: (650)851-7232 c n moiwv^ ^to^iifi > » ki. \p J riefRwji rR^ofw-a^oio.** 
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